This section is intended to provide a background or context to the invention that is recited in the claims. The description herein may include concepts that could be pursued, but are not necessarily ones that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, what is described in this section is not prior art to the description and claims provided herein and is not admitted to be prior art by inclusion in this section.
Location services can refer to those services which are based upon the location of a mobile device. Conventional location services (LCS) architectures can be divided into two categories, i.e., control plane architecture and user plane architecture, according to the type of communications engaged in between relevant elements. In a control plane architecture, location determination can be done according to 3rd Generation Partnership Project (3GPP) standards using embedded signaling protocols. In addition, 3GPP standards can also involve the use of a base station subsystem (BSS)-centric architecture. Other methods of location determination are based on a network subsystem (NSS)-centric architecture, although more recent 3GPP standards releases, e.g., rel4, no longer employ the NSS-centric solution. Alternatively, a user plane architecture can be characterized as an overlay solution. In other words, a data connection on a user plane between a relevant server and a terminal, e.g., user equipment (UE), is used to transfer radio interface information, satellite information, and/or other information needed to determine location.
Furthermore, the 3GPP is moving towards the 4th generation of radio technologies, with the advent of Long Term Evolution (LTE) technology/standardization. Location-based technology in the context of LTE includes an LTE positioning protocol (LPP) described in the LPP specification “3GPP TS 36.355 Stage 3” which can be found on the 3GPP website. LPP, architecturally-speaking, is used “point-to-point” between a target (e.g., a UE to be positioned) and a server (e.g., a location server providing, for example, positioning instructions and assistance), in order to position the target using position-related measurements obtained by one or more reference sources. In user plane deployments, LPP is encapsulated as a sub-protocol to the UserPlane Location Protocol (ULP), i.e., ULP is the carrier protocol for LPP. ULP is defined in Open Mobile Alliance Secure User Plane Location Protocol (OMA SUPL). Release 2.0 and the later releases of SUPL support the encapsulation of LPP.
In a relative positioning method, one device is positioned with respect to another device. The purpose is to determine the relative position (baseline) between the two devices accurately, not necessarily the absolute position of the devices. Relative positioning can be performed between two terminals or between a terminal and a reference station. Moreover, a multi-baseline solution may be implemented with the baselines being solved between multiple devices.
A simple form of relative positioning involves the difference in positions of two devices. However and oftentimes, relative positioning refers to higher-accuracy methods including, e.g., a satellite navigation technique referred to as Real-Time Kinematic (RTK), that generally achieves sub-decimeter (sub-dm) accuracies. RTK navigation is reliant upon obtaining continuous periodic carrier and code phase measurements from two Global Navigation Satellite System (GNSS) receivers, which can be terminals and/or virtual/physical reference receivers. These measurements are linearly combined in a manner such that common mode errors negate/cancel each other out. For example, when the baseline is short, atmospheric errors (e.g., reduced group speed of propagation through the troposphere and ionosphere) are canceled out. For professional applications, dual-frequency global positioning systems (GPS) receivers are often used. Having a dual-frequency capability allows for, e.g., compensating for residual ionosphere errors. In the event that a baseline is short and the common mode errors are assumed to cancel out, single-frequency receivers can be used. Hence, the shorter the baseline is, the more straightforward and easier it becomes to accurately solve the baseline. It should be noted that RTK requires continuous periodic measurements (code and/or carrier phase) from the receivers.
Assistance data for assisted navigation systems, such as a GNSS, have been specified and standardized for cellular systems, e.g., GPS, European Galileo, and Russian Global Navigation Satellite System (GLONASS). An exemplary GNSS can comprise a network of satellites that broadcasts navigation signals including time and ranging data. GNSS receivers pick up these broadcasted navigation signals and calculate a precise global location based thereon. Other examples of GNSS include, but are not limited to, satellite-based augmentation systems (SBAS), local area augmentation systems (LAAS), quasi-zenith satellite systems (QZSS), and hybrid receivers.
The delivery of such assistance data can be built on top of cellular system-specific control plane protocols including, e.g., the radio resource location services protocol (RRLP) for GSM networks, the radio resource control (RRC) protocol of layer 3 in wideband code division multiple access (WCDMA) networks, and IS-801 for Code Division Multiple Access (CDMA) networks, standardized in the 3rd Generation Partnership Project (3GPP) and 3GPP2 standards.
Periodic assistance is not currently defined in any standard(s), but may be implemented, for example, in the context of RTK, because as indicated above, RTK requires a continuous periodic stream of reference measurement assistance. It should be noted that periodic assistance may be utilized in other contexts as well. A periodic assistance session is characterized by at least two session parameters: frequency (e.g., how often an assistance payload is delivered); and duration (e.g., how long the periodic assistance session lasts/will last). Moreover, a request for assistance should include information regarding the type of data that a requestor wishes to receive.
Further still and regarding periodic assistance in general, yet another session parameter may comprise the continuity of the periodic assistance, as there is a subtle difference between periodic assistance and continuous periodic assistance. For example, a device may request periodic assistance data to be delivered every ten minutes for a local troposphere model. In this instance, the server periodically provides the local troposphere model to the target for atmosphere error correction. However, although the delivery was initiated by the same request, the assistance data deliveries are independent in the sense that each of the deliveries can be used on its own, i.e. the model obtained at the time tk+10 min replaces the model obtained at tk.
In contrast, RTK, for example, requires continuous periodic assistance data. That is, the assistance data deliveries at tk and tk+1 are not independent. Rather, the time series matters. Thus the additional session parameter to be considered could be an indication, if the session is, in addition to being periodic, also a continuous one with respect to the data in the assistance delivery. It should be noted however, that all the periodic sessions are continuous in the sense that, e.g., all the assistance data deliveries belong to the same assistance data session or transaction.
In the context of LPP, assistance data is requested using a “LPP Request Assistance Data” (target→server) message, where the assistance data is delivered in a “LPP Provide Assistance Data” (server→target) message. Although the LPP specification (described in “3GPP TS 36.355 Stage 3 Functional Specification of UE positioning in E-UTRAN”found on the 3GPP website) allows for multiple and successive “Provide” messages, a requester is still not able to request (continuous) periodic assistance.
In addition to a typical “Request-Provide” interaction, LPP also allows for the unsolicited provision of assistance data. That is, a server may push assistance data to the target, without the target first requesting it. This is useful when, for instance, the server “knows” that the target will eventually request certain assistance data. An example of such a scenario occurs in a UE-based, GNSS-based session, in which the server can be sure that after commanding such a positioning method, the target will send a request for ephemerides. The server may act pro-actively and push the assistance data to the target without an explicit request from the target requesting such assistance data.
However, providing “unsolicited” periodic assistance data is problematic in the case of a periodic session, because the target is unaware that the session that has been started is a periodic one. Moreover, the target does not know how long the session will last, or at what frequency it will receive data. Moreover and as discussed above, in some cases, the target might be unaware of whether the periodic session contains continuous data or not. It is acknowledged, however, that in the majority of the cases, the target can deduce, based on the data type, whether the session is meant to be a periodic one or a continuous periodic one.
Furthermore and during a target-server interaction, the server ultimately decides what the session parameters are. Hence, even though a target may request certain frequency and duration of data, the actual session parameters accepted by the server may be parameters that are different from that which the target originally requested. Therefore and in this situation, the server may provide periodic assistance data with session parameters that are unknown to the target. Further still and in the event that the server changes session parameters (due to resource constraints, for example) during the session, the target is unaware of these changes to the session parameters. Ultimately, in case the server starts a periodic session unsolicited, the target does not know about the session parameters, or in a worst-case scenario, the target is completely unaware that the assistance session is a periodic one and that more data will follow after the first delivery. If the target requests changes in the session parameters, the server may or may not accept the modification, and the target will not know whether or not the changes were accepted by the server. Moreover, yet another case may arise where the server accepts the modified session parameters in a partly modified manner. For example, if the session has session parameters, e.g., “duration=A” and “frequency=B” and the target requests the session to be modified so that the duration parameter is now “duration=C” and the frequency parameter is now “frequency=D,” the server may “partly” accept the modification such that after the modification, the session parameters would result in “duration=C” and “frequency=B”